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>.wTnr ATrnFMAU. : II hereby certify ihat this correspondence is being unnsiiiiUcclvin 
CLASS M Aiuo th. Cou^missioncr l\^r Palcnis,, P.O. Box 1450. Alcx.ndr.a. VA 223 13- 
. .^^vn ihe (Intc shown below. 



TN THE UNITFrt STATES PATENT AND TTR APFMARK OFFICE 



In re Patent Application of: 
Charles PACLAT et al. 

Application No.: 09/975,945 Group Art Unit: 2124 

Filed: October 11, 2001 Examiner: Anil KHATRT 

For: METHOD FOR DEVELOPING BUSINESS 
COMPONENTS 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 223 13- 1450 

DECLARATION UNDER 37 C.F.R. S 131 

Dear Sir: 

I, CHARLES PACLAT DECLARE AND STATE THAT: 

1. I am the inventor of the "Method for Developing Business Components" 
described and claimed in the above-identified U.S. Patent Application ("the Present 
Application"). 

2. I was advised and therefore believe that the Present Application claims the 
benefit of U.S. Provisional Patent Application Serial No. 60/239,409 filed October 11, 
2000 ("the Provisional Application")- 

3. The Present Application was assigned to BEA Systems, Inc. by me on 
December 12, 200L Exhibit A is a copy of the Notice of Recordation of Assignment 
document evidencing the recordation of the assignment on January 22, 2002. 



25'l(i't64'). I 



1 




g|002 



THEOR 205.1 US (10107436) 



4. Well prior to August 24, 2000, the claimed invention shown and described 
in the provisional and present applications was conceived and reduced to practice. 

5. Exhibit B is a document written well prior to August 24, 2000 and provides 
an overview of New Component Development Process. (The actual data has been 
redacted from this document). 

6. Exhibit C is a document written well prior to August 24 ,2000 and provides 
a description of the New Component Development Process. (The actual date has been 
redacted from this document). 

7. We further declare that all statement made herein of our own knowledge 
are true and that all statements made on information and belief are believed to be true; 
and that these statements were made with the knowledge that willful, false statements and 
the like so made are punishable by fine or imprisonment, or both, under Section 1001 of 
Title 18 of the United States Code and that such willftil, false statements may jeopardize 
the vahdity of die application or any patent issuing thereon. 
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C. ANDREW IM 
666 FIFTH AVE. 
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Chief Information Officer 
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UNITED STATES PATENT AND TRADEMARK OFFICE 
NOTICE OF RECORDATION OF ASSIGNMENT DOCUMENT 

THE ENCLOSED DOCUMENT HAS BEEN RECORDED BY' THE ASSIGNMENT DIVISION OF 
THE U.S. PATENT AND TRADEMARK OFFICE. A COMPLETE MICROFILM COPY IS 
AVAILABLE AT THE ASSIGNMENT SEARCH ROOM ON THE REEL AND FRAME NUMBER 
REFERENCED BELOW. . ' ■ 

PLEASE REVIEW ALL INFORMATION CONTAINED ON THIS NOTICE. THE 
INFORMATION CONTAINED ON THIS RECORDATION NOTICE REFLECTS THE DATA 
PRESENT IN THE PATENT AND TRADEMARK ASSIGNMENT SYSTEM. IF YOU SHOULD 
FIND ANY ERRORS OR HAVE QUESTIONS CONCERNING THIS NOTICE, YOU MAY 
CONTACT THE EMPLOYEE WHOSE NAME APPEARS ON THIS NOTICE AT 7 03-308-9723. 
PLEASE SEND REQUEST FOR CORRECTION TO: U.S. PATENT AND TRADEMARK OFFICE, 
ASSIGNMENT DIVISION, BOX ASSIGNMENTS, CG-4 , 1213 JEFFERSON DAVIS HWY, 
SUITE 320, WASHINGTON, D.C. -20231. 



RECORDATION DATE: 01/22/2002 REEL/FRAME: 012497/0313 

NUMBER OF PAGES: 3 

BRIEF: ASSIGNMENT OF ASSIGNOR'S INTEREST (SEE DOCUMENT FOR DETAILS). 

DOC DATE: 12/12/2001 



ASSIGNOR: 

P ACL AT, CHARLES 



ASSIGNEE: 

BEA SYSTEMS, INC. 

2315 NORTH FIRST STREET 

SAN JOSE, CALIFORNIA 95134 

SERIAL NUMBER: 09975945 
PATENT NUMBER: 



FILING DATE: 10/11/2001 
ISSUE DATE: 



KIMBERLY WHITE, EXAMINER 
ASSIGNMENT DIVISION 
OFFICE OF PUBLIC RECORDS 



FULBRIGHT ^JAWORSTQ L^P 

W YORK DOCi:2T7NG 
Docketed □ Not Renuired □ 
Previcu^lyD Updated Q>— 

Action: ' — ■ 

Reminder: ~ " — ~ 
Date: Due/;Do^e 
Initials: 



le/Done 
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(Rev. 6-93) 
0MB No. 0651-001 
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To the Honorable Commissioner of Patents and Trademarks: Please record the attached original documents or copy thereof. 



L Name of conveying party (ies): 

Charles PACLAT 

Additional name(s)ofconveyingparty(ies) attached? O Yes S No 



3. Nature of conveyance: 

B Assignment 

□ Security Agreement 

□ Other 



□ Merger 

□ Change of Name 



Execution Date: December 12. 2001 



2. Name and address of receiving party(ies): 
Name: BEA Systems. Inc. ™_— 



Internal Address: 
Street Address: 



2315 North First Street 



San Jose. California 95134 



Additional name(s) & address(es) attached? □ Yes E No 



Application number(s) or patent number(s): 

If this document is being filed together with a new application, the execution date of the appHcation is:. 
A. Patent Application No.(s) B. Patent No.(s) 

09/975,945, 



Additional numbers attached? □ Yes S No 



5. 



Name and address of party to whom coirespondence 
concerning document should be mailed; 



Name: C. Andrew Im 



Internal Address: FULBRIGHT & JAWORSKI L.L.P. 



Street Address: 



666 Fifth Avenue 



Total number of applications and patents involved: HI 

T^tnl fp^mr^T^ g V4n S40.00 

E Enclosed 

□ Authorization to be charged to deposit account 



City: New York State: NY Zip: 10103 



Deposit Account Number: 



500624 



(Attach duplicate of this page if paying by Deposit Account) 



DO NOT USE TfflS SPACE 



9. 



Statement and signature. 

To the best of my knowledge and belief, the foregoi 
original document. 

• C. Andrew Im 



Name of Person Signing 




;t and any attached copy is a tme copy of the 



December 13. 2001 



Signature 



/ 



Tottl number of pages including cover sheet, attachment, and document: 



Date 
□ 



Ol/Kf/aOOa LKUELLER 00000177 09975945 Mj 
01 Fl::581 



il documents to be recorded with required cover sheet information to: 

OP Commissioner of Patent and Trademarks, Box Assignments 
Washington, D.C. 20231 
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ASSIGNMENT 

WHEREAS, I, as a below nmned inventor, residing at the address stated next to ray 
name, am a sole inventor (if only one name is listed below) or a joint inventor (if plural names are 
listed below) of certain and useful improvements in METHOD FOR DEVELOPING 
BUSINESS COMPONENTS for which an application for Letters Patent of the United States of 
America was executed by me on the date indicated next to my name and address; 

AND WHEREAS, BEA Systems, Inc. with principal offices located 2315 North 
First Street, San Jose, CA 95134 (hereinafter referenced as ASSIGNEE) is desirous of acquiring 
all interest in, to and imder said invention, said application disclosing the invention and in, to and 
under any Letters Patent or similar legal protection which may be granted therefor in the United 
States and in any and all foreign countries; 

NOW THEREFORE, in consideration of the sum of One Dollar ($ 1 .00), and other 
good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, I, 
as a sole or joint inventor as indicated below, by these presents do hereby assign, sell and transfer 
unto the said ASSIGNEE, its successors, assigns, and legal representatives, the enth^ right, title and 
interest in the said invention, said application, including any divisions and continuations thereof, and 
in and to any and all Letters Patent of the United States, and countries foreign thereto, which may 
be granted for said invention, and in and to any and aU priority rights and/or convention rights under 
die International Convention for the Protection of Industrial Property, Inter- American Convention 
Relating to Patents, Designs and Indusnial Models, and any other iatemational agreements to which 
t).ie United States of America adheres, and to any other benefits accruing or to accrue to me with 
respect to the filing of applications for patents or securing of patents in the United States and 
countries foreign thereto, and I hereby authorize and request the Commissioner of Patents to issue 
the said United States Letters Patent to said ASSIGNEE, as the assignee of the whole right, title and 
interest thereto; 

And I fiirther agree to execute all necessary or desirable and lawful future documents, 
including assignments in favor of ASSIGNEE or its designee, as ASSIGNEE or its successors, 
assigns and legal representatives may from time-to-time present to me and without further 
remuneration, in order to perfect title in said invention, modifications, and improvements in said 
invention, applications and Letters Patent of the United States and countries foreign thereto; 

And I further agree to properly execute and dehver and without further remuneration, 
such necessar>^ or desirable and lawfhl papers for application for foreign patents, for filing 
subdivisions of said application for patent, and or, for obtaining any reissue or reissues of any Letters 
patent which may be granted for my aforesaid invention, as the ASSIGNEE thereof shall hereafter 
reqmre and prepare at its own expense; 
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And I fiirtber agree lhat ASSIGNEE will, upon its request, be provided promptly witii 
all pertinent facts and docmnents rdating to said application, said invention and said Letters Patent 
and legal equivalents in foreign countries as may be known and accessible to me and will testify as 
to the same in any interference or litigation related tliereto; 

And I hereby covenant that no assignment, sale, agreement or encumbrance has been 
or will be made ox entered into which would conflict with this assignment and sale. 

This assignment executed on the dates indicated below. 



Charles P ACLAT 



Name of first or sole inventor 



114 Wolcott Street 
Medford, MA 02155 




Signature of first or si 



Date of this assignment 
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A process for the discovery and implementation of generic 
business components. 




A PROCESS FOR THE DISCOVERY AND IMPLEMENTATION OF GENERIC BUSINESS 
COMPONENTS 

The New Component Development 



Introduction 



Building Business Objects 

This docLiment outlines a process by which BEA/ eSolutions will create object 
oriented representations of the software components that facilitate a vast array of 
business solutions. It identifies the key steps that are needed to build these 
components and provides guideHnes for the order of their execution. Underlying 
the concepts in this document are some key guiding principles that should be kept in 
mind throughout. 

Developing Business Objects 

Developing business objects differs firom developing end user applications. The 
traditional end user is the person that is using an appKcation to complete their daily tasks. 
In the case of business objects the end users are software developers and business 
analysts. Ultimately it is these users that will be customizing these components to create 
the complete solutions that the customers demand. 

Business objects also differ from the development of traditional software tools and 
infirastructure. This end user in these cases is only the software developer. Such tools 
rarely contain business domain specific logic. They can be designed and developed with 
no input ftom the business domain experts. 

Business object development requires much greater collaboration between the business 
analysts and the software engineering teams. The result wiU be well-structured 
components that capture the most important facets of a business domain. 

Time to Market 

The abilitj^ to deliver components in a timely manner is an overriding concern in today's 
extremely competitive marketplace. One of the key premises is that up front research will 
allow us to define the segments of the space where we can provide value added and 
where we shoxald form relationships. With this in mind it is important to be thorough 
but timely in the analysis. The typical up front analysis should consume no more than a 
few weeks. 



Iterative Development 

It should be stressed that these steps are not to be executed in a rigidly defined sequence. 
The onfy hard and fast rule is that a thorough market analysis must be done up front 
This will allow the design and implementation phases to be completed in an environment 
of full disclosure. It is expected that a veiy scaled back version of the components will 
be delivered after the first iteration. Each of the iterations will provide feed back into the 
anafysis and design, and will result in a product that is increasingly complete. 

Flow of Participation 

An important technique that is used in the NCD Process is the overlapping of team 
members as development passes through the various phases. Each phase of development 
will involve participants from the functional organizations that follow it in the process. 



Concept Exploration 




Analysis Phase Des^n Phase tmplementation Release and Support 

Phase Phase 



Concept Exploration 

The initiation of a new suite of components is within the product management team. It is 
important that there be significant contributions fi-om the sales and professional services 
teams. Typical functional representation will be 50% Product Management, 20% 
Professional Services, 15% Sales, and 15% Engineering. 

Requirements Analysis 

The second phase is a more detailed analysis of the functional requirements from a 
standpoint of implementing the functionality of a set of components. Typical functional 
representation will be 60% Product Management and 40% Engineering. 

Architectural Design 

The process of turning the functional requirements into an object oriented model that 
encapsulates the data model and the process model. At this point the weighting shifts to 
75% Engineering and 25% Quality Assurance. 

Detailed Design, Implementation and Test 

This phase consists of a more detailed version of the architectural design, implementation 
of the business logic, and software testing of the components in hand At this point the 
typical functional representation will be 70% Engineerii^, 20% Quality Assurance, and 
10% Documentation. 

Deliver Component 

The process of delivering the components in a timely manner into the market place. At 
this point the weighting will be 50% Quality Assurance, 30% Documentation, 20% 
Support, and 10% Engineering. 

Change Requirements Analysis 

The feedback from the customers is analyzed to incorporate the changes in the newer 
versions of the components. It is important to delegate the required upgrade based upon 
its type (see Appendix A) to the corresponding phase in the process. The typical 
weighting at diis point is 60% Support, 20% Sales, and 20% Professional Services. 

Parallel Development 

In many cases there are opportunities to improve time to mari^et by performing steps in 
parallel. This is especially true with regard to the implementation, of the components and 
the building of the demonstration or prototype application. It is expeaed that once the 
initial design of the components is complete, the implementation of the components and 
the building of the prototype will provide opporuanities for improvement. 

In general the development process will involve parallel iterations of the product and 
associated demonstration applications. 
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Target Functionality 

In almost all cases our objective is to establish an immediate produa presence in the 
Enterprise Java Beans Component market. In many cases this will mean replicating a 
base line product offering in our first iteration. In such cases our advantage will be in the 
fact that we are EJB and that the components are built as eBSCs and are extensible and 
configurable. In follow on iterations we will push past the state of the art and deliver 
functionality that exceeds that of our competitors. 

Versioning of Components 

In all cases, our primarj^ concem is to keep our customers on the newest version of our. 
components. The new version might include not only new functionality, but also bug 
fixes to code they already use, performance improvements, support for new platforms 
etc. The versioning scheme for our components tries to make upgrades easy, predictable 
and desirable is described in Appendix A. 

increased Quality 

The delivery of high quality software components is an extremefy- overridii^ concem in 
today's market. Use of such reusable software components will result in a system with 
increased quality since these components are pre-fabricated (i.e., pre-implemented) and 
pre-tested (i.e., certified) components. The greater the reuse of a component, the greater 
will be the quality of the system using it since the errors must have been eliminated. 

Reduction in Development Costs 

Increased quality results in decreased development costs. Use of pre-tested reusable 
software components decreases the cost incurred in performing various quality assurance 
activities to detea the errors in the design specifications and implementation. 



Analysis 



Defining the scope of the htisiness functionalify 

The first phase of each New Component Development undertaking defines the 
scope of the business functionality for a new set of components firom the Theorj^ 
Center. This phase involves a small team including one or two member firom the 
NCD team and additional domain knowledgeable resources firom the 
architecture or professional services teams. The deliverable firom this process is the 
completion of die NCD Definition. 

The NCD Definition is a single document that summarizes research into an entire 
business domain. The "divide and conquer" approach is taken such that once a wide 
reaching NCD is completed it is likely that it will be divided into additional sub domains 
that are then reciirsively refined as NCD's of their own. This process continues until 
manageable units of functionality are arrived at 

The NCD Definition itself is composed of the following major sections. 

Summary of Scope 

The docximent begins with an overview of the business problem that is being addressed. 
The purpose of this section is to set the context upon which the rest of the research is to 
be completed. The content should address the concerns of a typical end user of the 
targeted solution. The tone should be that of an expert in the field explaining the issues 
to an outsider. 

List of inputs 

Once the scope of the business problem is defined, the process of identifying resources 
that relate to the problem are identified, assembled and summarized. The following 
major groupings are specifically addressed. 



Interacting Components 

This section describes components or other parts of the system that this component will 
interact with. It should just be a simple buUeted list of items naming the component and 
what functionality is needed from that component. The list should strive for 
completeness as it will not only be useful for helping readers of this NCD better 
understand the component, but it will also help with cross-NCD dependency tracking. In 
this phase this section might include some components that may or may not actually be 
interaaed with. An example section is: 

• Interacts with Inventory component to know what is in stock. 

• Interaas with the Shipping component to determine how much shipping will 
cost. 

• Migjit use the Payment component to authorize payments. 
Industry Analysts 

In many cases analysts have initiated much of the research into a given sector. Gathering 
and reading targeted analysts reports is generally the first step towards gaining an 
understanding of the domain. 

Related industry Standards 

Another prime source of information are standards bodies and or professional societies. 
These organizations represent the contribution of the best thinking in a given domain. 
They often have the aim of publishing standards that represent the functionality common 
across an array of vendors. The colleaed publications and standards are collected into a 
repository. TTie list of member companies in such consortiums is a window onto the 
collection of vendors that are offering solutions in a given domain. 

Commercial Packages ( Competitors / Partners ) 

The reference documentation and feature sets of commercial software packages are also 
gathered. The superset of the most prominent features is the ultimate solution to the 
problem that is being addressed. The union of the features in these products generally . 
represents the baseline functionality for a produa offering. During this process it is 
important to foster positive relationships with vendors. In many cases we may simply be 
providing a generic interface that will be used to wrap third party solutions. Such 
"adapters" are only possible with the cooperation of the parmer. 

Related Engagements and System Integrators ( Customers ) 

The woric that is accomplished in extending our components to meet the needs of our 
customers is one of our best resources. It is for this reason that it is important to include 
representatives from the architectural and professional services teams in this part of the 
process. A corporate knowledge base of documentation from all professional services 
eng^ements must be maintained and referenced for recoverable intellectual property. 



Additional In-house Resources 

Many of the companies best resources lies in the past experience of the current staff. For 
this reason it is important to publish the goals of the NCD to the rest of the company 
and elicit input from all interested parties. The presence of such resource should be 
noted and they should be included as advisors during the second phase of the process. 

eFunction Matrix 

Upon completion of the list of inputs the creation of a eFunction matrix is initiated. The 
eFunction matrix is accomplished by first collecting an all encompassing list of features 
from all of the inputs listed. The features, or eFunctions, must be described in a summary 
of less than five words. These eFuncrions are collected into groups or packages. Longer 
descriptions are bound to these short descriptions and cross referenced. The 
eFunctions are listed as the first column of a grid A template of the resulting table is 
presented below. 
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The table is divided into 5 major sections. The first section lists each "eFunction" and the 
package or grouping to which it belongs. The second section lists the development status 
with regard to any pre-existir^ functionality in house and the importance of the feature as 
a gauged by competitors, customers, and partners. The Competitors section contains a 
column for each software solution that can be considered a competitor. For each 
eFimction an ad-hoc scoring from 1-10 is provided where 10 is a complete solution to 
that eFunction. The Customers section provides a place to record both customer 
requests as well as cases in which customers have implemented or extended otir . 
components to encompass a function that we did not provide. The Partners section is 
where opportunities to leverage partnerships are recorded. In many cases it may be 
difficult to distinguish partners from competitors until the analysis is completed. 



This matrix is important becatise it provides a single place in which all of the options are 
quantified and can be compared and contrasted. 

Action Items 

The final deliverables fi-om the first phase include: 

1. A list of targeted features 

2. The team composition for the second phase. 

Once these deliverables are done, the stage is set for the beginning of the second Phase of 
the NCD process. 



Design 



Object Oriented Analysis and Design (OOAD) using UML 

The focus of this phase is to perform an in-depth analysis of the resources defined 
in the first phase. The second phase is used to refine the general descriptions 
created in die first phase into a design document from which implementation 
can be started. From the phase one documentation, the actors and dien the use 
cases will be extracted. The use cases can then be used to fill in the detail for each of the 
components that are to be constructed. 

Overview of Usage 

A more refined version of the Siommary of Scope firom the first phase is completed. This 
defines the specific functionality that will be covered in the first implementation of this 
NCD. This allows the team to specifically state what will and will not be covered in this 
release. In addition it is often good practice to describe a future course of action for 
implementing extended fiInctionalitJ^ 

Interacting Components 

This section describes the refined version of die section, interacting components firom the 
analysis phase. The components or other parts of the system that this component may 
not interact with will be filtered out in tins phase. It will be a list of specific components, 
whose functionalit)^ will be needed by the component in hand. 

A Glossary of Domain Specific Terms 

It is important to begin by defining the temis that may be ambiguous or unfamiliar to the 
reader. This will ensiire that the content which follows is cleariy understood. 

A List of the Actors and a Description of Roles 

The individual users and or external systems diat are to interact with the newly developed 
component must be listed. This includes: 

■ End users 



■ Institutions providing a particular service 

■ Specific proprietary legacy systems 

■ Systems accessed by industry standard protocols 

Such entities must be identified and their role in the business process clearly explained. 



A Collection of Use Cases 

Use cases are as defined in the Unified Modeling Language (UML). The UML is an^ 
industry standard notation for describing object orient systems. The use cases describe 
the business process in simple narrative form. The relationships between the actors and 
the use cases are visualized in lise case diagrams and then these use cases are transformed 
into interaction diagrams that describe the operations that actors initiate on objeas as well 
as objea-to-objea operations. Their purpose is to help the developer of the system 
identify the components and the operations that will need to be performed upon them. 
For more on use cases refer to The Unified Software Development Process, by Ivar 
Jacobson, Grady Booch, and James Rumbaugh. In many cases it is helpful to begin the 
development of a prototype as part of the use case exercise. This prototype application 
will often take the form of a graphical front end that implements the system from the 
aaors perspective. This will provide the designers the opportunity to explore the use 
cases in depth. 

Mapping Protocols to Objects 

Beyond the standard mechanisms provided in the UML for defining components, it is 
also useful to consider some other techniques designed to exploit existing message 
passing formats. In the case where an existing message format exists, such as a 
Document Type Definition pTD) for the eXtensible Markup Language (XML\ the 
following guidelines can be used to create an initial component model: 

1. Objects should be identified from the message formats. For instance, if there are 
"New Order" and "Cancel Order" messages in a given protocol it is likely a good 
idea to create an "Order" object. In many cases die existence of die telltale 
create, refresh, update, and delete (CRUD) messages signify that tiiere is some 
underlying entity that needs to be modeled. 

2. The methods on each object should be identified. Many times tiiis will be simpfy 
translating a message such as "Cancel Order" to the "cancel" metiiod on the 
"Order object". Odier times tiiis might involve combining multiple messages 
into a single method call. For example, the messages "Begin Transaction", "End 
Transaction" and 'Update Order" mi^t just be translated into an "update" 
method on the "Order" objea diat sends all tiiree messages in die appropriate 
order. 



3. The identity of the remote object is captured in a set of attributes that capture the 
primary key of the entity. Typically the values will be named appropriately as 
"identifier", "name", or "key". 

4. Look also for session based components that simply specify that some action is 
to be performed but do not identify an entity. 

Initial UML Models with Documentation 

Once the use case anafysis is complete the initial component models will be completed 
using the UML class diagrams and the Theory Centers specialized stereotypes. The 
process of applying the Theory Center's mapping of UML to Enterprise Java Beans is 
described in tiie document "Modeling with eBusiness Smart Components". 

Test Cases 

The creation of test cases is the last deliverable in the design phase. The test cases 
provide an important validation of the design. By designing the test cases before 
implementation begins, the Quality Assurance team is given an opportunity to have input 
into the design before implementation has begun. Performing this simple step earfy on 
lays the groundwork for having high quality components. 



Design Review 

The completion of the Design Phase is marked with a formal review. All of the above 
deliverables are reviewed for content and form. The design review will include senior 
development staff from Engineering, Architecture, and Professional Services, as well as 
representatives from the Sales and Marketing teams. This will provide the opportunity 
for the organization to provide additional feed back before implementation begins and to 
buy in to die target components 
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Implementation 



Building the New Components. 

The third phase of the New Component Development is the implementation of 
the components themselves. At this point in the development the relational 
mappings and deployment descriptors are generated. This will include the 
definition of secudtj^ roles. A complete set of unit tests that exercise the 
functionalitj^ will be included. This phase may be completed in parallel with 
implementation of a reference implementation. The implementation will proceed within 
the following guidelines. 
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Component Generation 

The first step is the creation of implementation is the generation of the classes that 
represent the components and their Java Doc from the model. The components are then 
compiled and deployed with the simplest form of persistence. The completion of 
deplcyable components makes it possible to begin the implementation, unit test creation 
and documentation in parallel. 

Deployment with Container Managed Persistence (CMP) 

This involves installing the bean class and its supporting classes in the EJB server with 
container-managed persistence. Using this type of persistence, the container must keep 
the objea and the database synchronized i.e., the container is responsible to fetch the data 
from tlie database and put it in the bean and also to write the data back to the database 
(the ejUoadO and qbsiureO methods will not be used to access the database). This is the path 
of lease resistance implementation that allows the creation of a non-optimized solution 
that can be used in the creation of biisiness logic, unit tests and the reference 
implementation. 

End User Documentation 

This involves creating documentation that is targeted at the end-user developer. The 
documentation team will use the design documentation and the java documentation and 
prepare it for consumption by outsider parties. The documentation to this point has 
been focused on determining what the functionality should be. As such it contains 
references to functionality that we may choose not to implement and product 
comparisons that must be eliminated. 

Unit Test Construction 

The QA team will begin the design of tests that fulfy exercise the components. This 
process begins before the components have been full implemented. It is important that 
the test plans be created and written by a team that is not biased by knowing the 
implementation details of the components (i.e.: "black-box" testing). 

implement Business Logic/Legacy System Integration 

Legacy system integrations is concerned with the integration of legacy applications and 
data into a distributed computing environment. In many instances the implementation of 
the business logic will not be objea-oriented but must appear to be object-oriented in 
distributed environment as these applications are of greater use. Software components 
can be used as a "wrapper" to make these applications appear as though they are object- 
oriented. Business logic may be added in the form of methods and the implementation of 
this business logic amounts to functional substance to the components. 



Documentation Verification 

Upon completion of the implementation and the documentation, the two must be 
brought back into synch. This should focus on confirming that the documentation 
matches the implementation, as additional details ma^^ have been uncovered during 
implementation that required functionality changes that now need to be documented. 

Unit Test Verification 

Upon completion of the implementation and the unit tests, the components must be 
verified. 

Packaging 

The creation of a reference implementation using the components and the packaging 
with regard to deployment sets is the final phase of the implementation. 
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Demonstration 

Creating a reference implementation 

The final phase of the NCD process involves the creation of a demonstration application that 
fully utilizes the components in a functioning application. This is a final step that proves out 
the design and makes the components accessible to the business population. A different team 
than those who built the components should assemble the application. This will help to 
ensure that the documentation and design will make sense to our user communit}^ Any 
required changes to the design or documentation will be made in an update diat follows. 

In many cases the development of the demonstration application can begin prior to the completion of 
the implementation. In particular the design of the user interface and the logical flow will be based off 
of the documentation tiiat results firom the design phase. Beginniag tiiis process as early as possible 
win help to discover any flaws in the design before the implementation has proceeded too far. 
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Release and Support 

RdeasingthepnxhictWc^tJomersa^ 

Once the produa development is complete and a reference implementation has been 
created, it must be released. This'includes the gathering of the documentation, updates 
to the release notes (as needed), creation of the installable image (e.g.: an InstallShield 
image), final testing of the installable image, and distribution of the product (e.g.: we b 

release). 

After release customer support must help with installation issues, configuration and us^e 
problems. Also, customer support must funnel back bugs, requests for new features and other 
comments and suggestions fi-om the customers to the rest of engineering. 
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Appendix A 



Versioning of Components 

introduction 

It is in both our customers' and our best interest to keep our customers on the newest 
version of our components. It is in our customers' best interest because they get the latest 
and the greatest. This might include not only new functionality, but also bug fixes to code 
they akeady use, performance improvements, support for new platforms, etc. It is in our 
interest because no matter how few versions of our software we want to support, in reality 
we must support whatever versions our customers are using. Therefore, having them all on 
the newest version (or at least almost the newest version) will greatly reduce the number of 
releases we must support. 

In any product, managing backwards compatibility such that development progress is not 
halted and current customers are not angered by the coiistant changes is a difficult challenge. 
The challenges become greater as the software product includes more programmability - it is 
easier to change one's mouse motions to accommodate GUI changes than it is to reprogram 
all of one's Excel macros because the macro language just changed. Our components, by 
their very nature, are used as integral portions of large and complex programs making 
managing backwards compatibility for us an even greater challenge for us than it is for most 
software vendors. 

This situation is complicated by the fact that we are developing new releases at a very rapid 
rate, currently four per year. This means that if we only support 12 months worth^ of 
product we would end up supporting three or four active products while we are in the midst 
of developing yet another. Such a support effort will surely grind us to a halt. Furthermore, 
as our customer base continues to grow, we must make upgrading to new versions easy, 
predictable and desirable. If not we will spend more and more of our time handholding 
the customer through upgrades, explaining to them what the problems are as they try to 
upgrade and arm-twisting them to upgrade. 

The remainder of this document describes an approach to developing new versions of our 
components that would try to make upgrades easy, prediaable and desirable. The approach 
taken is based off of the recognition that there is a tradeoff between the complexity of 
changes we can add to a release and the ease with which the customer can upgrade. That is, 
the more we restrict the types of changes between releases, the easier an upgrade will be. 

Diffierent Types of Upgrades 

Following is a list of types of upgrades where each successive type of upgrade gives us more 
flexibility (i.e.: allows greater enhancements) but also requires more work on the part of the 
customers when they upgrade. 



Upgrade 
Type 


Tyf 

Bug 
Fixes 


>es of Changes 

New 
Behavior 


Allowed 
Modify 
Existing 
Behavior 


Server 


Requires 1 

Development Machine 


Jpdate 

Client 


Model and 
Software 


Bug Fix 
Only 


Yes 


No 


No 


Required 


Only if changes are 
needed on development 
machine. 


No 


No 


Added 
Behavior 


Yes 


Yes ■ 


No 


Required 


Required 


Required 


Only if new 
features are 
used. 


Major 
Release 


Yes 


Yes 


Yes 


Required 


Required 


Required 


Required 



Bug Fix Only: The bug fix only upgrade is characterized by the fact that it introduces no 
(let me repeat, "no") changes to the model or to the behavior of any method. It will typically 
consist of bug fixes only although performance improvements, documentation changes and 
other modifications are also permissible. Belongings, being both server and cUent entities, 
cannot be upgraded at all. The user can install a Bug Fix upgrade without changing any code 
or doing anything to their Rose models. They just install the product on the server and 
developer machines and continue working as before. Some releases will not even need to be 
installed on the developer machines. For example, performance improvements or fixes for 
bugs that only happen when the component is under heavy load are probably not needed on 
the development machines. 

Added Behavior: In addition to allowing for bug fixes, this upgrade type allows for the 
addition of new classes as well as for the addition of new methods to existing classes. A new 
method" is either a method of a new name, or a new overload for an existing method. This 
type of upgrade does not allow for the deletion of an existing method or the changiiig of 
behavior of an existing method. Since this type of upgrade allows a class definition to 
change it will need to be installed on all servers, clients and development machines. 

Major Release: This is an all-is-fair release. That is, this release makes no commitment to 
backward compatibility in anyway. It will need to be installed everywhere and existing code 
will need to be ported to the new components. 

Please note that this should not be misconstrued as an exhaustive list of all upgrade types. 
The three upgrade types discussed here have close cousins, each with sUghtly differentiy 
semantics. For example, we could have a Client Bug Fix upgrade that would be just like a 
Bug Fix upgrade but it would have to be installed on each client and developer machme as 
well. This would allow, among other things, changes to Belongings. Another possible 
upgrade type would be a New Component upgrade that allows bug fixes and the addition of 
new components but does not allow changes to existing ones. The three upgrade types 
discussed here are just three reasonably spaced points across the broad spectrum of possible 
upgrade types. 

Naming the Releases 

Note: This section is pending vnjomiadon ahmtvemoninga^ BEA. It will be adjusted to 

satisfy any BEA conventions as needed 



The releases should be named to inform the customer what type of changes they are getting 
in an upgrade, how major the changes are and how difficvilt the upgrade will be. The 
following naming convention meets these requirements: 





Type of Release 


Examples of 
Release Name 


Bug Fix Only 


Dot-dot release 


2.0.1, 2.3.5 


Added Behavior 


Dot release 


2.1,2.2 


Major Release 


Dot-oh release 


2.0, 3.0 



Technological Assistance 

We can use some technological solutions to simplify the implementation of these policies in 
the following ways: 

1 . Make the upgrade easy for the customer by simplifying the work they need to do 
to upgrade existing models in Rose. 

2. Ensure that we do not violate a release's constraints. For example, we must 
ensure that a bug fix release does not add new methods or objects. 

3. Simplify the cost of upgrading to the next major release by allowing for parallel 
development. 

Upgrading Rose Models 

When a user wants to work with our components in Rose they do so by utilizing our .CAT 
files (Rose Category files). By doing this, the model for our components are stored in 
different files than the model for the user's components and classes. By updating our .CAT 
files, we can cause Rose to add both new components as well as new behavior to existing 
components without requiring the user to make any change in their model. Once the .CAT 
files are updated, the next time the user opens a model utilizing our components they will 
see the upgraded model. 

Ensuring a Release's Constraints Are Met 

The constraints on an Added Behavior upgrade are that the behavior of existing methods is 
kept the same and that no methods are deleted. Unfortunately it is impossible to ensure that 
the behavior of existing methods stays the same (remember the Halting Problem). We can 
however write a tool to ensure that no methods are deleted. The tool would simply run 
javap on the old and new class definitions and compare the output (this is trickier than a 
simple difference but not difficult). A bug fix release has the added constraint that it does 
not change any class definitions at all. Another tool (or the same tool with a different 
option) would do a difference and ensure that the class definitions have not changed at all. 

Parallel Development 

A major release places a large burden on the customer because they must rework their model 
and the corresponding code. Because of this, we cannot expect them to upgrade an entire 
large system all at once. There are three scenarios for partial upgrades: 



a) A developer might begin work using a new major release of our components while 
still maintaining a release using an older release. It would be convenient if they could 
do this on the same machine. 

b) If they are running multiple applications on their web server, time may force them to 
upgrade some appUcations but not others to the newest major release. 

c) They may wish to upgrade some parts of a system to the new components but not 
the rest. That is, they may wish to have a single application that uses multiple 
versions of our components. 

By changing our package naming scheme to include the Major Release number we can 
ensiu-e that two releases of our components can reside in the same VM. This will enable 
scenarios (a) and (b) above. Enabling the partial upgrade described in (c) is significantly 
harder and while perhaps possible (through the use of the Adapter pattern), will not be 
further discussed here. 

Conclusion 

This versioning scheme is far from complete. Investigation still needs to occur to determine 
exactly what should and should riot be allowed in each type of upgrade. For example, 
should we not bother with Bug Fix upgrades and instead have Client Bug Fix upgrades? The 
trade-offs need to be better understood before final decisions can be made. Furthermore, 
this scheme is limited to versioning of our components. A similar scheme will need to be 
developed for our tools. 

That being said, this versioning scheme has two key features, predictability and ease of 
installation. It is predictable because our customers can tell simply by comparing version 
numbers what types of changes are in a new release as well as what the complexity of the 
upgrade will be. By easily being able to upgrade to new minor releases (i.e.: dot and dot- 
dot) we can greatly limit the amount of support we provide. For example, if, in a year we 
release 2.0, 2.0.1, 2.1, 2.2 and 3.0, we can tell our customers that we only are supporting 2.2 
and 3.0. Due to the backwards compatibility constraints of minor releases all 2.x customers 
using versions prior to 2.2 can easily upgrade to 2.2 without jeopardizing their work (we, of 
course, will never introduce a regression and will assure our customers of that ©). 



